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- The MAILING DATE of this communication appears on the cover sheet with the correspondence address — 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) OR THIRTY (30) DAYS, 
WHICHEVER IS LONGER, FROM THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 .136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
eamed patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1 )^ Responsive to communication(s) filed on 22 April 2010 . 
2a )^ This action is FINAL. 2b)n This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1935 CD. 11, 453 O.G. 213. 

Disposition of Claims 

4) ^ Clalm(s) 1.2.4.7-16.18 and 19 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) \Z\ Claim(s) is/are allowed. 

6) |EI Claim(s) 1.2.4.7-16.18 and 19 is/are rejected. 
/)□ Claim(s) is/are objected to. 

8) 0 Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) 0 The specification is objected to by the Examiner. 

10) ^ The drawing(s) filed on 09 January 2006 is/are: a)^ accepted or b)^ objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1.85(a). 
Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 

1 1) 0 The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-152. 

Priority under 35 U.S.C. § 119 

12) 0 Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (f). 
a)n All b)n Some * c)^ None of: 

1 .□ Certified copies of the priority documents have been received. 

2. n Certified copies of the priority documents have been received in Application No. . 

3. n Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 



Attach ment(s) 

1 ) □ Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-413) 

2) □ Notice of Draftsperson's Patent Drawing Review (PTO-948) Paper No(s)/Mail Date. . 

3) □ Information Disclosure Statement(s) (PTO/SB/08) 5) □ Notice of Informal Patent Application 

Paper No(s)/Mail Date . 6) □ Other: . 

'TOL-326 (Rev. 08-06) Office Action Summary Part of Paper No./Mail Date 20100712 
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DETAILED ACTION 

1. This action is in response to the filing on April 22, 2010. Claims 1, 2, 4, 7-16, 18, and 19 
are pending and have been considered below. The applicant has canceled claims 3,5,6, 17, and 
20. 

Priority 

2. Acknowledgement is made of applicant's priority of United States Provisional Patent 
Application Number 60/486,560 filed on July 11, 2003. 

Claim Rejections - 35 USC § 102 

3. The following is a quotation of the appropriate paragraphs of 35 U.S. C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, pubhshed under section 122(b), by another filed 
in the United States before the invention by the appUcant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the Enghsh language. 

4. Claims 1, 2, 4, 7-16, 18, and 19 are rejected under 35 U.S.C. 102(e) as being anticipated 
by Ritz et al. (US 7,263,632 B2). 



As per claim 1 : A method for monitoring application exceptions generated by a software 
application, comprising: 
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dynamically identifying an occurrence of an application exception generated by the 

software application prior to said application exception being logged 

Ritz discloses [col. 06, lines 38-50] the monitoring service applies policy to filter which events 

are propagated up to invoke diagnostic module for root cause determination. Examples of such 

events may be desirable include enterprise environments where an IT manager or system 

administrator may prefer that the operating system not perform certain automatic root cause 

determination and/or problem resolutions actions automatically. Therefore, the operating system 

is capable of dynamically identifying root cause determination. 

collecting exception data responsive to said application exception; 

examining said exception data, prior to said application exception being logged, to 

determine whether said application exception is a critical exception that will lead to a 

failure of said application and to identify critical exception data; 

dynamically determining whether said critical exception is a primary exception or a 

derived exception, prior to said application exception being logged; and 

Ritz discloses [col. 05, lines 27-43] the event provider communicate events to a logger. 

Accordingly, any given event provider need not generate an event for every interaction it senses, 

but may generate only the more relevant events relating to root causes of problems [identifying 

critical exception]. For example, an event need not be generated every time a disk drive writes 

to a sector [non-critical event]. However, an event might be generated if the disk drive fails to 

respond to a read or write command [critical event]. The logger makes these determinations 

before the event has been logged to the event trace log file. Ritz further discloses [col. 09, lines 

6-24] if the vendor is unable to determine the root cause, the vendor may use update service to 
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instruct diagnostic policy service to store additional event or state information to event trace log 
file [critical exception is a primary exception]. The resolution module may likewise instruct the 
logger to store additional events in order to ensure that proper resolution is achieved. When the 
additional information is transmitted to the error reporting service after the next occurrence of 
the problem [critical exception is a derived exception], the additional information may enable the 
vendor to better identify the root cause of the problem. 

logging said critical exception data responsive to whether said critical exception event is 
said primary exception or derived exception. 

Ritz further discloses [Abstract] the diagnostic module queries the log file to correlate events 
relevant to diagnosis of the problem, and identifies the root cause by evaluating the results of the 
query. Once the root cause of the problem is diagnosed, a resolution module corresponding to 
that root cause may be invoked to programmatically resolve the problem. 

As per claim 2: The method of Claim 1, wherein said operating includes operating said 
software application in at least one of a .NET framework and a J2EE framework [Abstract; 
operating system (Windows)]. 

As per claim 4: The method of Claim 1, further comprising processing said critical 
exception data responsive to at least one of said primary critical exception and said derived 
critical exception. 
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Ritz discloses [Abstract] events are monitored within an operating system, and at least a subset 
of the events are logged to a log file. It is understood that a new event logged would be a 
primary critical exception. If a similar log exists, it would be a derived critical exception event. 

As per claim 7: The method of Claim 1, wherein said examining includes examining said 
critical exception data to determine if an exception chain exists. 

Ritz discloses [col. 06, lines 14-22] the diagnostics policy service determines when an actual 
problem has occurred by, for example, detecting a predetermined single error condition, or by 
detecting a predetermined sequence of error conditions has arisen [exception chain exists]. 

As per claim 8: The method of Claim 4, wherein said processing further includes collecting 
critical exception data responsive to said critical exception and creating an exception 
information database. 

Ritz discloses [Abstract] events are monitored within an operating system, and at least a subset 
of the events are logged to a log file [information database]. 

As per claim 9: The method of Claim 8, wherein said processing further includes creating a 
critical exception chain. 

Ritz discloses [col. 06, lines 14-22] the diagnostics policy service determines when an actual 
problem has occurred by, for example, detecting a predetermined single error condition, or by 
detecting a predetermined sequence of error conditions has arisen [exception chain exists]. Ritz 
fiirther discloses [col. 06, lines 23-29] once a problem is detected, the computing system 



Application/Control Number: 10/564,106 Page 6 

Art Unit: 2114 

performs a functional result-oriented step for programmatically diagnosing a problem evidenced 
by the one or more error conditions. 

As per claim 10: The method of Claim 7, wherein said processing further includes 
associating said collected critical exception data with said critical exception chain. 

Ritz discloses [col. 06, lines 14-22] the diagnostics policy service determines when an actual 
problem has occurred by, for example, detecting a predetermined single error condition, or by 
detecting a predetermined sequence of error conditions has arisen [exception chain exists]. Ritz 
further discloses [col. 06, lines 23-29] once a problem is detected, the computing system 
performs a functional resuh-oriented step for programmatically diagnosing a problem evidenced 
by the one or more error conditions. 

As per claim 1 1 : The method of Claim 1, wherein said processing further includes 
comparing said critical exception data with data contained within an exception information 
database to determine whether said exception is said critical exception [col. 07, lines 32-63]. 

As per claim 12: The method of Claim 1, wherein said examining further includes labeling 
said exception as at least one of a critical exception, a non-critical exception, a derived 
exception and a primary exception. 

Ritz discloses [col. 07, lines 46-63] if the query results are associate with an identified root 
cause, the invoked diagnostics module may invoke an appropriate resolution module to perform 
an identified resolution that corresponds to the identified root cause. The identified root cause 
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for a problem is some problem that is known to exist [derived exception event]. It is understood 
that if a problem is not known to exist, it would be a primary exception event. 
Ritz further discloses [col. 09, lines 6-9] if the error event does not have a known root cause 
associated with it [critical exception], diagnostics module will report this information to the 
activity log, which in turn sends an error report to error reporting service. It is understood that if 
the error even does have a known root cause, it can be fixed with predetermined instructions to 
follow [non-critical exception]. 

As per claim 13: The method of Claim 12, wherein said processing further includes 
updating said exception information database with said exception data [col. 08, lines 53-60]. 

As per claims 14-16 and 18: Although claims 14-16 and 18 are directed towards a system claim, 
they are rejected under the same rationale as the method claims 1,3,2, and 4, respectively. 

As per claim 19: Although claim 19 is directed towards a machine-readable medium claim, it is 
rejected under the same rationale as the method claim 1 . 

Response to Arguments 

5. Applicant's arguments filed on September 14, 2009 have been fully considered but they 
are not persuasive. In response to applicant's argument that Ritz is not capable of dynamically 
determining the occurrence of or responding to an exception event, the examiner respectfiiUy 
disagrees. Ritz discloses [col. 09, lines 6-24] if the vendor is unable to determine the root cause. 
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the vendor may use update service to instruct diagnostic policy service to store additional event 
or state information to event trace log file. The resolution module may likewise instruct the 
logger to store additional events in order to ensure that proper resolution is achieved. When the 
additional information is transmitted to the error reporting service after the next occurrence of 
the problem, the additional information may enable the vendor to better identify the root cause of 
the problem. Since the root cause was not determined, it is clear that the event was not 
propagated to invoke diagnostic module. Therefore, Ritz is capable of dynamically determining 
the occurrence of an exception event without propagating to invoke diagnostic module. 
6. In response to applicant's argument that Ritz does not determine the type of critical 
exception and process the critical exception responsive to the type of critical exception, the 
examiner respectfully disagrees. Ritz discloses [col. 09, lines 6-24] if the vendor is unable to 
determine the root cause, the vendor may use update service to instruct diagnostic policy service 
to store additional event or state information to event trace log file. The resolution module may 
likewise instruct the logger to store additional events in order to ensure that proper resolution is 
achieved. When the additional information is transmitted to the error reporting service after the 
next occurrence of the problem, the additional information may enable the vendor to better 
identify the root cause of the problem. Therefore, it is clear that primary exceptions store more 
information while trying to find a root cause. The derived exceptions would not need to store 
further information because the root cause of the problem is already known. 
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Conclusion 

7. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS fi-om the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to JIGAR PATEL whose telephone number is (571)270-5067. The 
examiner can normally be reached on Mon-Fri 10:00AM-6:30PM. 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, Scott Baderman can be reached on 571-272-3644. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained trom the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/Scott T Badcrman/ 

Supervisory Patent Examiner, Art Unit 2114 

/Jigar Patel/ 
Examiner, Art Unit 2114 



